COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002
C00009 ENDMK
C⊗;

		   Third LISP Newsletter: Sept 27, 1979

Here's number three; late as usual. Hopefully, by this time you have  seen
the August issue of  BYTE magazine. They are  somewhat more dependable  in
their production schedule than I am.

As I mentioned in the last letter, I expect RESPONSE from you.  As yet  no
one has objected to publishing the membership list in the newsletter;  one
more month, and it happens.

Several interesting  things have  been  going on  since the  last  letter.
First, I observed some of the "goings on" at the UC Santa Cruz Programming
Methodology Summer  Short  Course.  There was  a  strong  anti-interactive
atmosphere; not  just anti-interactive  programming, but  anti-interactive
editing as well. One expected to hear the old anti time-sharing  arguments
from the early 60's again.  The general effect was most depressing.

Partly as a reaction to this and  partly because it's just a good idea,  I
am resurrecting my plan to have  a LISP Conference next year.  The  thrust
of the  Conference is  the non-AI  aspects of  LISP-related  developments:
languages, programming, theory,  and applications;  yes, even  programming
methodology, from the LISP  point-of-view.  The initial  plan is to  shoot
for the last week in August 1980.  Here's a general outline of what's up.

Architecture:  projects  range from  re-microcoded commercially  available
hardware to specially designed LISP chips.

Languages and Theory: applicative languages, object-oriented languages and
formal semantics of LISP-like languages

Programming  and  Environments:  LISP's  flexible  programming   behavior,
including the support systems which surround the language.

Applications: non-traditional applications-- mathematics, music, graphics,
and what-have you. 

The conference should be a very exciting  and positive event for computer
science.

-----
Lots  of micro LISPs are creeping around now (I will soon enter the fray with
with one myself for the Z-80). There are two major problems which must be
dealt with: some implementations are "toys", either in capabilities or in
speed or BOTH. Such implementations are based on a simplified view of what
LISP is. For example, "theoretically" LISP is definable in terms of 
five simple primitives and conditional expressions, plus an 
implementation of the run-time system (some toys don't even supply all of that)
and some simple I/O routines.  Such LISP's do little to dispell the myth that
LISP is an unpleasant collection of parentheses, unmanageable, dull, and
slow. A production LISP is further from this toy-view than, say, UCSD Pascal
is from an trivial arithemetic programming language which only supplies
the addition operation, if-then-else, and numeric reading and printing 
functions. A production LISP  is a systems programmer's tool box, full of
data structuring devices, scanners, parsers, unparsers, symbol table 
organizers, compilers, editors, debuggers, ... all INTEGRATED into a 
uniformly accessible system. To advertize LISP as something less, is a disservice.
Economic reality can creep in of course; a truly integrated system requires
all kinds of bells and whistles which are currently beyond  reasonable pricing
for personal systems. However, the concept --the ideal--, must not be compromised.
Alas, many of the new micro implementations view LISP in this restricted
perspective. 

The second problem is just the proliferation of LISP dialects. This can be as
deadly as the preceding problem. 
Before you conclude that I am advertising an ANSI standard LISP, let me assure
you that I am NOT. I am generally opposed to standardization efforts.
I would rather see a de facto standardization, occurring out of usage not out
by edict. I would hope that some of our efforts will build to such a 
consensus.

do vlisp